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Abstract 


This document specifies the Deterministic Networking data plane when Time-Sensitive 
Networking (TSN) networks are interconnected over a DetNet MPLS network. 
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1. Introduction 


June 2021 


The Time-Sensitive Networking Task Group (TSN TG) within the IEEE 802.1 Working Group deals 
with deterministic services through IEEE 802 networks. Deterministic Networking (DetNet) 
defined by the IETF is a service that can be offered by an L3 network to DetNet flows. General 


background and concepts of DetNet can be found in [RFC8655]. 
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This document specifies the use of a DetNet MPLS network to interconnect TSN nodes/network 
segments. The DetNet MPLS data plane is defined in [RFC8964]. 


2. Terminology 


2.1. Terms Used in This Document 


This document uses the terminology and concepts established in the DetNet architecture 
[RFC8655] [RFC8938] [RFC8964]. TSN-specific terms are defined in the TSN TG of the IEEE 802.1 
Working Group. The reader is assumed to be familiar with these documents and their 
terminology. 


2.2. Abbreviations 


The following abbreviations are used in this document: 


AC Attachment Circuit 

CE Customer Edge equipment 
d-CW DetNet Control Word 

DetNet Deterministic Networking 

DF DetNet Flow 

FRER Frame Replication and Elimination for Redundancy (TSN function) 
L2 Layer 2 

L2VPN Layer 2 Virtual Private Network 
L3 Layer 3 

LSP Label Switched Path 

LSR Label Switching Router 

MPLS Multiprotocol Label Switching 


MPLS-TE Multiprotocol Label Switching - Traffic Engineering 


NSP Native Service Processing 

OAM Operations, Administration, and Maintenance 

PE Provider Edge 

PREOF Packet Replication, Elimination and Ordering Functions 
PW Pseudowire 

S-PE Switching Provider Edge 
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T-PE Terminating Provider Edge 


TSN Time-Sensitive Network 


2.3. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario 


Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN-aware DetNet service running 
over an MPLS network. DetNet edge nodes sit at the boundary of a DetNet domain. They are 
responsible for mapping non-DetNet-aware L2 traffic to DetNet services. They also support the 
imposition and disposition of the required DetNet encapsulation. These are functionally similar 
to PW T-PE nodes, which use MPLS-TE LSPs. In this example, TSN Streams are simple 
applications over DetNet flows. The specifics of this operation are discussed later in this 
document. 


TSN Edge Transit Edge TSN 
End System Node Node Node End System 
(T-PE) (LSR) (T-PE) 
+---------- + +---------- + 
| TSN | <--------= End-to-End TSN Service --------- > | TSN 
| Applic. | | Applic. | 
+---------- POE a ak + E T + +---------- + 
l IDI NSSBirnoxy = :$-Proxy/ | | | 
l TSN |] +,.+---+<-- DetNet flow -->+---+ | | | TSN 
l | |TSN| SYC] [svel |TSN| | l 
+---------- + +---+ +---+ +---------- +  +---+ +---+} +---------- + 
| 2 | | L2| |Fwd| | Forwarding | |Fwd] |L2 | | L2 | 
+------ .---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------ + 
Link : ff geass 2 N nk: Ho paan SN 
FORE ENE + +-[ Sub- ]-+ FE E + +-[ TSN ]-+ 
[Network] [Network] 
[Reese DetNet MPLS ------ > 
[RRR ree SSS arene VELU ee a a > 


Figure 1: A TSN over DetNet MPLS-Enabled Network 


In this example, edge nodes provide a service proxy function that "associates" the DetNet flows 
and native flows (i.e., TSN Streams) at the edge of the DetNet domain. TSN Streams are treated as 
App-flows for DetNet. The whole DetNet domain behaves as a TSN relay node for the TSN 
Streams. The service proxy behaves as a port of that TSN relay node. 
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Figure 2 illustrates how DetNet can provide services for IEEE 802.1 TSN end systems, CE1 and 
CE2, over a DetNet-enabled MPLS network. Edge nodes E1 and E2 insert and remove the required 
DetNet data plane encapsulation. The 'X' in the edge nodes and relay node, R1, represent a 
potential DetNet compound flow packet replication and elimination point. This conceptually 
parallels L2VPN services and could leverage existing related solutions as discussed below. 


TSN |<------- End-to-End DetNet Service ------ >| TSN 

Service | Transit Transit | Service 
TSN (AC) l |<-Tnl->| |<-Tn1->| | (AC) TSN 
End l V V V \ 2 N V l End 
System | +-------- + +-------- + +-------- + | System 
+---+ | l E1 |=======]| R1 [====--- E2 | | aaa 
l =a Rea] a eaaa le Da ea a a a la Da er aa atea al l 
|CE1| | | \ | I Pres | Lf | | |CE2 | 
l l l Noe e aR e Ne e Da a l l 
a | |======= | |=======| | Soot 

A +-------- + +-------- + +-------- + A 

| Edge Node Relay Node Edge Node | 

l (T-PE) (S-PE) (T-PE) l 

| | 

|<- TSN -> <------- TSN over DetNet MPLS ------- > <- TSN ->| 

| | 

| <-------- Time-Sensitive Networking (TSN) Service ------- >| 

X Service protection 

DFx = DetNet member flow x over a TE LSP 


AC = Attachment Circuit 
Tnl = Tunnel 


Figure 2: IEEE 802.1TSN over DetNet 


4. DetNet MPLS Data Plane 


4.1. Overview 


The basic approach defined in [RFC8964] supports the DetNet service sub-layer based on existing 
PW encapsulations and mechanisms and supports the DetNet forwarding sub-layer based on 
existing MPLS Traffic Engineering encapsulations and mechanisms. 


A node operating on a DetNet flow in the DetNet service sub-layer, i.e., a node processing a 
DetNet packet that has the S-Label as top of stack, uses the local context associated with that S- 
Label. For example, a received F-Label can be used to determine what local DetNet operation(s) 
is applied to that packet. An S-Label may be unique when taken from the platform label space 
[RFC3031], which would enable correct DetNet flow identification regardless of which input 
interface or LSP the packet arrives on. The service sub-layer functions (i.e., PREOF) use a DetNet 
control word (d-CW). 
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The DetNet MPLS data plane builds on MPLS Traffic Engineering encapsulations and 
mechanisms to provide a forwarding sub-layer that is responsible for providing resource 
allocation and explicit routes. The forwarding sub-layer is supported by one or more forwarding 
labels (F-Labels). 


DetNet edge/relay nodes are DetNet service sub-layer aware, understand the particular needs of 
DetNet flows, and provide both DetNet service and forwarding sub-layer functions. They add, 
remove, and process d-CWs, S-Labels, and F-Labels as needed. MPLS DetNet nodes and transit 
nodes include DetNet forwarding sub-layer functions — notably, support for explicit routes and 
resource allocation to eliminate (or reduce) congestion loss and jitter. Unlike other DetNet node 
types, transit nodes provide no service sub-layer processing. 


4.2. TSN over DetNet MPLS Encapsulation 


The basic encapsulation approach is to treat a TSN Stream as an App-flow from the DetNet MPLS 
perspective. The corresponding example is shown in Figure 3. Note that three example flows are 
shown in the figure. 


/-> +------ + +------ + +------ + TSN By os 
MPLS | | xX EX EX |<- Appli 
App-Flow <-+ +------ + +------ + +------ + cation : :(1) 
| |TSN-L2| |TSN-L2|  |TSN-L2| ny 
\-> +---+======ł}--+======+}--+======+----- + 
| d-CW | | d-CW | | d-CW | 
DetNet-MPLS +------ + +------ + +------ + (2) 
|Labels| |Labels| |Labels| v 
4---+==5=5=55=54--455=5=5=55+--+5=====4+----- + 
Link/Sub-Network e |e SSN E | UDP | 
+------ + +------ + +------ + 
| IP || 
+------ + 
an 
+------ + 


(1) TSN Stream 
(2) DetNet MPLS Flow 


Figure 3: Examples of TSN over MPLS Encapsulation Formats 


In the figure, "Application" indicates the application payload carried by the TSN network. "MPLS 
App-Flow" indicates that the TSN Stream is the payload from the perspective of the DetNet MPLS 
data plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate multiple TSN Streams. 


Note: Network fragmentation for DetNet is not supported and MUST be avoided. The 
reason for this is that network fragmentation is not consistent with the packet 
delivery times needed for DetNet. Therefore, when IP is used as the sub-network, 
IPv6 fragmentation MUST NOT be used, and IPv4 packets MUST be sent with the DF 
bit set. This means that the network operator MUST ensure that all the DetNet 
encapsulation overhead plus the maximum TSN App-flow frame size does not 
exceed the DetNet network's MTU. 
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5. TSN over MPLS Data Plane Procedures 


The description of edge node procedures and functions for TSN over DetNet MPLS scenarios 
follows the concepts from [RFC3985] and covers the edge node components shown in Figure 1. In 
this section, the following procedures of DetNet edge nodes are described: 


e TSN related (Section 5.1) 
e DetNet Service Proxy (Section 5.2) 
e DetNet service and forwarding sub-layer (Section 5.3) 


The subsections describe procedures for forwarding packets by DetNet edge nodes, where such 
packets are received from either directly connected CEs (TSN nodes) or some other DetNet edge 
nodes. 


5.1. Edge Node TSN Procedures 


The TSN TG of the IEEE 802.1 Working Group has defined (and is defining) a number of 
amendments to [[EEE8021Q] that provide zero congestion loss and bounded latency in bridged 
networks. [[EEE8021CB] defines packet replication and elimination functions for a TSN network. 


The implementation of a TSN entity (i.e., TSN packet processing functions) must be compliant 
with the relevant IEEE 802.1 standards. 


TSN-specific functions are executed on the data received by the DetNet edge node from the 
connected CE before being forwarded to connected CE(s) or presented to the DetNet service 
proxy function for transmission across the DetNet domain. TSN-specific functions are also 
executed on the data received from a DetNet PW by a PE before the data is output on the AC(s). 


The TSN packet processing function(s) of edge nodes (T-PE) belongs to the NSP [RFC3985] block. 
This is similar to other functionalities being defined by standards bodies other than the IETF (for 
example, in the case of Ethernet, stripping, overwriting, or adding VLAN tags, etc.). Depending on 
the TSN role of the edge node in the end-to-end TSN service, selected TSN functions are 
supported. 


When a PE receives a packet from a CE on a given AC with DetNet service, it first checks via 
Stream identification (see Clause 6 of [IEEE8021CB] and [[EEEP8021CBdb]) whether the packet 
belongs to a configured TSN Stream (i.e., App-flow from the DetNet perspective). If no Stream ID 
is matched and no other (VPN) service is configured for the AC, then the packet MUST be 
dropped. If there is a matching TSN Stream, then the Stream-ID-specific TSN functions are 
executed (e.g., ingress policing, header field manipulation in the case of active Stream 
identification, FRER, etc.). Source Media Access Control (MAC) lookup may also be used for local 
MAC address learning. 


If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN- 
Stream-specific configuration to connected CE(s) (in case of local bridging) and/or to the DetNet 
service proxy (in case of forwarding to remote CE(s)). If there are no TSN-Stream-specific 
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forwarding configurations, the PE MUST flood the packet to other locally attached CE(s) and to the 
DetNet service proxy. If the administrative policy on the PE does not allow flooding, the PE MUST 
drop the packet. 


When a TSN entity of the PE receives a packet from the DetNet service proxy, it first checks via 
Stream identification (see Clause 6 of [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet 
belongs to a configured TSN Stream. If no Stream ID is matched, then the packet is dropped. If 
there is a matching TSN Stream, then the Stream-ID-specific TSN functions are executed (e.g., 
header field manipulation in case of active Stream identification, FRER, etc.). Source MAC lookup 
may also be used for local MAC address learning. 


If the PE decides to forward the packet, the packet is forwarded according to the TSN-Stream- 
specific configuration to connected CE(s). If there are no TSN-Stream-specific forwarding 
configurations, the PE floods the packet to locally attached CE(s). If the administrative policy on 
the PE does not allow flooding, the PE drops the packet. 


Implementations of this document SHALL use management and control information to ensure 
TSN-specific functions of the edge node according to the expectations of the connected TSN 
network. 


5.2. Edge Node DetNet Service Proxy Procedures 


The service proxy function maps between App-flows and DetNet flows. The DetNet edge node 
TSN entity MUST support the TSN Stream identification functions (as defined in Clause 6 of 
[IEEE8021CB] and [IEEEP8021CBdb]) and the related managed objects (as defined in Clause 9 of 
[IEEE8021CB] and [IEEEP8021CBdb]) to recognize the packets related to App-flow. The service 
proxy presents TSN Streams as an App-flow to a DetNet flow. 


When a DetNet service proxy receives a packet from the TSN entity, it MUST check whether such 
an App-flow is present in its mapping table. If present, it associates the internal DetNet flow ID to 
the packet and MUST forward it to the DetNet service and forwarding sub-layers. If no match is 
found, it MUST drop the packet. 


When a DetNet service proxy receives a packet from the DetNet service and forwarding sub- 
layers, it MUST be forwarded to the edge node TSN entity. 


Implementations of this document SHALL use management and control information to map a 
TSN Stream to a DetNet flow. N:1 mapping (aggregating multiple TSN Streams in a single DetNet 
flow) SHALL be supported. The management or control function that provisions flow mapping 
SHALL ensure that adequate resources are allocated and configured to fulfill the service 
requirements of the mapped flows. 


Due to the (intentional) similarities of the DetNet PREOF and TSN FRER functions, service 
protection function interworking is possible between the TSN and the DetNet domains. Such 
service protection interworking scenarios might require copying of sequence number fields from 
TSN (L2) to PW (MPLS) encapsulation. However, such interworking is out of scope in this 
document and is left for further study. 
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5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures 


In the design presented in [RFC8964], an MPLS service label (the S-Label), similar to a PW label 
[RFC3985], is used to identify both the DetNet flow identity and the MPLS payload type. The 
DetNet sequence number is carried in the d-CW, which carries the Data/OAM discriminator as 
well. In [RFC8964], two sequence number sizes are supported: a 16-bit sequence number and a 
28-bit sequence number. 


PREOF functions and the provided service recovery are available only within the DetNet domain 
as the DetNet flow ID and the DetNet sequence number are not valid outside the DetNet network. 
MPLS (DetNet) edge nodes terminate all related information elements encoded in the MPLS 
labels. 


When a PE receives a packet from the service proxy function, it MUST handle the packet as 
defined in [RFC8964]. 


When a PE receives an MPLS packet from a remote PE, then, after processing the MPLS label 
stack, if the top MPLS label ends up being a DetNet S-Label that was advertised by this node, then 
the PE MUST forward the packet according to the configured DetNet service and forwarding sub- 
layer rules to other PE nodes or via the DetNet service proxy function towards locally connected 
CE(s). 


For further details on DetNet service and forwarding sub-layers, see [RFC8964]. 


6. Controller Plane (Management and Control) Considerations 


Information related to TSN Stream(s) to DetNet flow mapping is required only for the service 
proxy function of MPLS (DetNet) edge nodes. From the data plane perspective, there is no 
practical difference based on the origin of flow-mapping-related information (management 
plane or control plane). 


The following summarizes the set of information that is needed to configure TSN over DetNet 
MPLS: 


e TSN-related configuration information according to the TSN role of the DetNet MPLS node, as 
per [IEEE8021Q], [IEEE8021CB], and [IEEEP8021CBdb]. 


e DetNet MPLS-related configuration information according to the DetNet role of the DetNet 
MPLS node, as per [RFC8964]. 


e App-flow identification information to map received TSN Stream(s) to the DetNet flow. 
Parameters of TSN Stream identification are defined in [[EEE8021CB] and [[EEEP8021CBdb]. 


This information MUST be provisioned per DetNet flow. 


Mappings between DetNet and TSN management and control planes are out of scope of the 
document. Some of the challenges are highlighted below. 
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MPLS DetNet edge nodes are a member of both the DetNet domain and the connected TSN 
network. From the TSN network perspective, the MPLS (DetNet) edge node has a "TSN relay 
node" role, so TSN-specific management and control plane functionalities must be implemented. 
There are many similarities in the management plane techniques used in DetNet and TSN, but 
that is not the case for the control plane protocols. For example, RSVP-TE and MSRP behave 
differently. Therefore, management and control plane design is an important aspect of scenarios 
where mapping between DetNet and TSN is required. 


Note that as the DetNet network is just a portion of the end-to-end TSN path (i.e., single hop from 
the Ethernet perspective), some parameters (e.g., delay) may differ significantly. Since there is no 
interworking function, the bandwidth of the DetNet network is assumed to be set large enough to 
handle all TSN flows it will support. At the egress of the DetNet domain, the MPLS headers are 
stripped, and the TSN flow continues on as a normal TSN flow. 


In order to use a DetNet network to interconnect TSN segments, TSN-specific information must 
be converted to DetNet-domain-specific information. TSN Stream ID(s) and stream-related 
parameters/requirements must be converted to a DetNet flow ID and flow-related parameters/ 
requirements. 


In some cases, it may be challenging to determine some information related to the egress-node. 
For example, it may be not trivial to locate the egress point/interface of a TSN Stream witha 
multicast destination MAC address. Such scenarios may require interaction between control and 
management plane functions and between DetNet and TSN domains. 


Mapping between DetNet flow identifiers and TSN Stream identifiers, if not provided explicitly, 
can be done by the service proxy function of an MPLS (DetNet) edge node locally based on 
information provided for the configuration of the TSN Stream identification functions (e.g., Mask- 
and-Match Stream identification). 


Triggering the setup/modification of a DetNet flow in the DetNet network is an example where 
management and/or control plane interactions are required between the DetNet and the TSN 
network. 


Configuration of TSN-specific functions (e.g., FRER) inside the TSN network is a TSN-domain- 
specific decision and may not be visible in the DetNet domain. Service protection interworking 
scenarios are left for further study. 


7. Security Considerations 


Security considerations for DetNet are described in detail in [DETNET-SEC]. General security 
considerations are described in [RFC8655]. 


Considerations specific to the DetNet MPLS data plane are summarized and described in 
[RFC8964], including any application flow types. This document focuses on a scenario where TSN 
Streams are the application flows for DetNet, which is already covered by those DetNet MPLS 
data plane security considerations. 
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8. IANA Considerations 


This document has no IANA actions. 
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